• Cargo.lock is excluded by: !**/*.lock
• contracts/injective-cosmwasm-mock/Cargo.toml is excluded by: !**/*.toml

• .github/workflows/Basic.yml (3 hunks)
• contracts/injective-cosmwasm-mock/src/contract.rs (2 hunks)
• contracts/injective-cosmwasm-mock/src/error.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/handle.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/lib.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/msg.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/order_management.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/reply.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/state.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/mod.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/query_exchange_derivative_tests.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/query_exchange_tests.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/types.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/utils.rs (1 hunks)
• packages/injective-cosmwasm/src/exchange/response.rs (1 hunks)
• packages/injective-cosmwasm/src/exchange_mock_querier.rs (2 hunks)
• packages/injective-cosmwasm/src/querier.rs (3 hunks)

• contracts/injective-cosmwasm-mock/src/testing/mod.rs

contracts/injective-cosmwasm-mock/src/lib.rs (1)

• 7-11: The addition of new modules handle, order_management, reply, state, and types is correctly implemented. Ensure that these modules are properly integrated and used throughout the contract to enhance its functionality as intended.

contracts/injective-cosmwasm-mock/src/state.rs (1)

• 5-11: The introduction of ORDER_CALL_CACHE and the CacheOrderInfo struct is correctly implemented. Ensure that interactions with this cache are properly handled, including error scenarios, to maintain the contract's robustness.

contracts/injective-cosmwasm-mock/src/error.rs (1)

• 8-13: The addition of new error variants UnrecognizedReply, ReplyParseFailure, and SubMsgFailure is correctly implemented. These errors enhance the contract's robustness by providing clear, context-specific error messages for reply handling scenarios.

.github/workflows/Basic.yml (1)

• 27-27: The update of the Rust toolchain version to 1.73.0 in the GitHub Actions workflow is correctly implemented. Ensure that the project builds successfully and all tests pass with this new toolchain version.

Also applies to: 44-44, 68-68, 76-76, 83-83

contracts/injective-cosmwasm-mock/src/msg.rs (1)

• 7-112: The addition of new message types and queries related to trading activities is correctly implemented. Ensure that these new messages and queries are properly integrated and used throughout the contract to enhance its functionality for handling complex market operations.

packages/injective-cosmwasm/src/exchange/response.rs (1)

• 102-102: The change to make aggregate_volumes an optional field in QueryAggregateVolumeResponse is correctly implemented. Ensure that this optionality is properly handled in the contract's logic to gracefully manage scenarios where no aggregate volumes are available.

contracts/injective-cosmwasm-mock/src/types.rs (1)

• 1-170: The introduction of new Protobuf message types for orders and related operations is correctly implemented. Ensure that these types are properly integrated and used throughout the contract to facilitate interactions with the Injective Protocol for creating and managing spot and derivative orders.

contracts/injective-cosmwasm-mock/src/contract.rs (5)

• 16-18: Constants CREATE_SPOT_ORDER_REPLY_ID and CREATE_DERIVATIVE_ORDER_REPLY_ID have been introduced to uniquely identify replies for spot and derivative order creations. This is a good practice as it helps in distinguishing between different types of replies in the contract's reply handler.
• 20-20: The constant MSG_EXEC is introduced for specifying a message type. Ensure that this constant is used consistently wherever applicable to avoid hardcoding the string in multiple places, which can lead to errors if the string needs to be updated.
• 30-51: The execute function's signature has been updated to handle new message types for testing transient spot and derivative orders. This is a significant enhancement as it allows for more comprehensive testing of the contract's functionality. Ensure that all new message types are properly validated within the function to prevent any potential misuse or errors.
• 57-127: The query function has been expanded with new query message types, significantly enhancing the contract's querying capabilities. It's important to ensure that all new query types are thoroughly tested to validate their correctness and to check for any potential security implications, such as unauthorized access to sensitive information.
• 132-136: The reply function has been updated to handle replies for creating spot and derivative orders. This is a crucial update for asynchronous order creation. It's important to ensure robust error handling for unrecognized reply IDs to prevent any unhandled cases that could lead to unexpected behavior.

contracts/injective-cosmwasm-mock/src/testing/query_exchange_derivative_tests.rs (9)

• 23-42: The test test_query_perpetual_market_info properly sets up the environment, queries the perpetual market info, and asserts the expected results. It's good practice to ensure that the assertions are specific and cover all relevant aspects of the response to ensure the test is robust and meaningful.
• 44-96: The test test_query_derivative_market demonstrates comprehensive testing of querying derivative market details. It includes setting up a market, querying it, and asserting various properties of the response. Ensure that edge cases, such as querying non-existent markets, are also covered to ensure the contract's robustness.
• 98-129: The test test_query_effective_subaccount_position focuses on querying the effective position of a subaccount in a market. It's important to test both positive and negative scenarios, including cases where the subaccount has no position in the market, to fully validate the contract's behavior.
• 131-172: The test test_query_vanilla_subaccount_position checks for the vanilla position of a subaccount in a market. Similar to the previous comment, ensure comprehensive coverage by including tests for various scenarios, such as empty positions and positions across multiple markets.
• 174-219: The test test_query_trader_derivative_orders effectively queries and asserts the properties of derivative orders for a trader. It's crucial to also test the behavior when there are no orders for the trader or when invalid parameters are provided to ensure the contract handles these cases gracefully.
• 221-239: The test test_query_perpetual_market_funding checks the funding state of a perpetual market. This is an important aspect of derivative markets. Ensure that the test covers various states of market funding, including scenarios where the market has undergone multiple funding intervals.
• 241-258: The test test_query_derivative_market_mid_price_and_tob queries and asserts the mid-price and top of the book (TOB) for a derivative market. This test is crucial for ensuring that market data is accurately reported. Consider adding tests for markets with no orders to ensure the contract handles these scenarios correctly.
• 260-309: The test test_query_derivative_market_orderbook provides a thorough examination of the order book for a derivative market. It's important to test various configurations of the order book, including empty order books and order books with a large number of orders, to ensure scalability and correctness.
• 311-362: The test test_query_trader_transient_derivative_orders focuses on querying transient derivative orders. This test is particularly important for ensuring that transient orders are handled correctly. Ensure that the cleanup of transient orders is also tested to prevent any potential leaks or unintended persistence of data.

packages/injective-cosmwasm/src/querier.rs (2)

• 12-12: The renaming of QueryAggregateVolumeResponse to QueryAggregateMarketVolumeResponse reflects a more specific naming convention that aligns with the functionality. This change improves code readability and clarity regarding the type of volume being queried.
• 343-351: The implementation of query_aggregate_market_volume using the newly renamed QueryAggregateMarketVolumeResponse is correct and aligns with the renaming objective. Ensure that all references to the old response type have been updated across the codebase to maintain consistency.

contracts/injective-cosmwasm-mock/src/testing/query_exchange_tests.rs (4)

• 50-63: The test test_exchange_params effectively queries and asserts the exchange parameters. It's well-structured and follows best practices for testing by asserting specific expected values. However, consider adding a brief comment explaining the significance of the values being asserted, such as why 604800 is expected for trading_rewards_vesting_duration, to improve maintainability and understandability for future contributors.
• 145-153: The test test_query_spot_market_no_market_on_exchange is concise and directly tests the scenario where no market is available on the exchange. This is a good example of a focused test case. However, ensure that the market ID used (0xd5a22be807011d5e42d5b77da3f417e22676efae494109cd01c242ad46630115) is intentionally chosen for this test scenario and does not inadvertently reference a real or potentially valid market ID that could exist in a live or test environment.
• 338-373: The test_query_market_volatility function correctly tests the market volatility query before and after adding new orders. However, the assertion that res.volatility equals Some(FPDecimal::ZERO) after adding new orders (line 373) might not always reflect realistic market conditions or the intended functionality of the volatility calculation. Ensure that this assertion accurately represents the expected outcome of the volatility query under the test conditions.
• 438-448: The test test_query_market_atomic_execution_fee_multiplier effectively queries and asserts the atomic execution fee multiplier for a market. The assertion at line 448 is clear and directly related to the test's purpose. However, similar to other tests, ensure that the hardcoded value human_to_dec("0.0000025", QUOTE_DECIMALS) accurately reflects the expected multiplier under the test conditions. Additionally, consider documenting the rationale behind this expected value for clarity.

contracts/injective-cosmwasm-mock/src/utils.rs (5)

• 1-7: The imports are well-organized and cover a broad range of functionalities required by the utility functions. It's good practice to keep imports tidy and grouped by their source or functionality, which has been done here.
• 43-57: The UserInfo and Setup structs are well-defined and serve as foundational elements for setting up tests and simulations. However, it's important to ensure that all fields, especially those like market_id in Setup, are used appropriately throughout the code to avoid unused data.

Verification successful

---

The verification process has confirmed that market_id is utilized effectively in the code, particularly in functions related to launching markets, adding orders, and initializing liquidity. This indicates that market_id serves its intended purpose within the Setup struct and the overall application logic, facilitating the simulation of market conditions for testing purposes. Therefore, the initial review comment is consistent with the codebase as market_id is indeed used appropriately.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that `market_id` is utilized effectively in the code.
rg 'market_id' contracts/injective-cosmwasm-mock/src/utils.rs

Length of output: 1788

* 59-63: The `ExchangeType` enum is a concise way to differentiate between spot, derivative, and none types. This approach simplifies decision-making in functions that depend on the type of exchange being simulated or tested. * 171-187: The `wasm_file` function dynamically constructs the path to the WASM file based on the contract name and architecture. This is a flexible approach, but ensure that the environment variable `ARTIFACTS_DIR_PATH` and the fallback directory `artifacts` are correctly configured in your CI/CD pipeline or local development environment. * 189-193: The `str_coin` function efficiently converts human-readable coin amounts to the `Coin` type expected by the Cosmos SDK. This utility function is crucial for simplifying the setup of account balances in tests. Ensure that the `human_to_dec` function, which it relies on, accurately handles various input formats.

packages/injective-cosmwasm/src/exchange_mock_querier.rs (1)

• 191-197: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [194-209]

The change from using a vector directly to wrapping the vector in Some() for the aggregate_volumes field within the default_aggregate_account_volume_handler() function is a positive improvement. It introduces optionality to the data structure, which is more flexible and semantically correct for scenarios where there might be no aggregate volumes to report. This change enhances the function's ability to accurately represent possible states of aggregate volumes.

• contracts/injective-cosmwasm-mock/src/contract.rs (2 hunks)
• contracts/injective-cosmwasm-mock/src/msg.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/authz.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/mod.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/query_exchange_derivative_tests.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/query_exchange_tests.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/utils.rs (1 hunks)

• contracts/injective-cosmwasm-mock/src/msg.rs
• contracts/injective-cosmwasm-mock/src/testing/mod.rs
• contracts/injective-cosmwasm-mock/src/testing/query_exchange_derivative_tests.rs
• contracts/injective-cosmwasm-mock/src/testing/query_exchange_tests.rs

contracts/injective-cosmwasm-mock/src/contract.rs (3)

• 16-21: The addition of new constants for reply IDs and message types (CREATE_SPOT_ORDER_REPLY_ID, CREATE_DERIVATIVE_ORDER_REPLY_ID, and MSG_EXEC) is clear and follows the Rust convention for constant naming. These constants are crucial for identifying different types of messages and replies within the contract, enhancing readability and maintainability.
• 29-51: The execute function signature has been updated to handle new message types for transient spot and derivative orders. This update is crucial for expanding the contract's functionality to support more complex market operations. The match statement is well-structured, ensuring that each message type is handled appropriately.
• 39-51: The addition of new functions handle_test_transient_spot_order and handle_test_transient_derivative_order within the execute function enhances the contract's capabilities to manage transient orders for spot and derivative markets. This is a significant improvement, aligning with the PR's objectives to expand testing coverage and functionality for complex market operations.

contracts/injective-cosmwasm-mock/src/utils.rs (1)

• 43-63: The introduction of the UserInfo and Setup structures, along with the ExchangeType enum, significantly improves the organization and readability of the code. These structures facilitate the setup and management of testing environments, making it easier to simulate different market scenarios. This is a positive change that enhances the maintainability and scalability of the testing framework.

• Cargo.lock is excluded by: !**/*.lock
• contracts/injective-cosmwasm-mock/Cargo.toml is excluded by: !**/*.toml

• contracts/injective-cosmwasm-mock/src/contract.rs (2 hunks)
• contracts/injective-cosmwasm-mock/src/handle.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/lib.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/msg.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/query.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/reply.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/mod.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/test_authz.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/test_exchange.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/test_exchange_derivative.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/testing/test_oracle.rs (1 hunks)
• contracts/injective-cosmwasm-mock/src/utils.rs (1 hunks)

• contracts/injective-cosmwasm-mock/src/handle.rs
• contracts/injective-cosmwasm-mock/src/lib.rs
• contracts/injective-cosmwasm-mock/src/msg.rs
• contracts/injective-cosmwasm-mock/src/reply.rs

contracts/injective-cosmwasm-mock/src/testing/mod.rs (1)

• 1-4: The module declarations are correctly formatted and follow Rust conventions. It's good practice to keep module names descriptive and concise, which has been achieved here. The renaming and addition of new modules indicate an expansion of testing capabilities, aligning with the PR's objectives.

contracts/injective-cosmwasm-mock/src/testing/test_authz.rs (1)

• 1-10: The imports and utility functions are correctly used and relevant to the tests being implemented. It's important to ensure that imports remain organized and only include what's necessary for the file's functionality to maintain readability and performance.

contracts/injective-cosmwasm-mock/src/testing/test_oracle.rs (2)

• 1-8: The imports and utility functions are correctly used and relevant to the tests being implemented. Organizing imports and ensuring only necessary modules are included is key to maintaining code readability and performance.
• 45-73: The test_query_oracle_volatility function follows a similar pattern to the previous test, correctly setting up and executing the test. The assertions at the end validate the absence of volatility and raw history in the response, which aligns with the expected behavior. This test demonstrates good practice by explicitly checking for the expected null values in the response.

contracts/injective-cosmwasm-mock/src/query.rs (1)

• 1-155: All query handler functions are correctly implemented, following a consistent pattern of converting query results to binary format using to_json_binary. This consistency is good for maintainability and readability. However, it's important to ensure that error handling is robust, especially when dealing with external data or queries that might fail. Consider adding more detailed error handling or logging to improve the resilience and debuggability of the contract.

Consider enhancing error handling in query functions to provide more detailed feedback in case of failures, which could improve debugging and resilience.

contracts/injective-cosmwasm-mock/src/contract.rs (2)

• 1-16: The file's structure and organization are well-maintained, with clear separation between imports, constants, and function definitions. The introduction of new constants for reply IDs and message types is correctly implemented, enhancing the contract's functionality and readability.
• 33-151: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [18-149]

The updates to function signatures and the addition of new functions for handling transient spot and derivative orders are correctly implemented. However, ensure that all new message types and reply IDs are thoroughly tested to prevent any unexpected behavior. Additionally, consider adding more detailed comments or documentation to new functions to improve maintainability and understandability for future contributors.

Consider adding more detailed comments or documentation to new functions, enhancing maintainability and clarity for future contributors.

contracts/injective-cosmwasm-mock/src/testing/test_exchange_derivative.rs (2)

• 1-22: The imports and utility functions are correctly used and relevant to the tests being implemented. Keeping imports organized and including only necessary modules is key to maintaining code readability and performance.
• 23-239: The test functions are well-structured, setting up the testing environment and querying various aspects of the derivative market. The assertions at the end of each test ensure that the expected behavior matches the actual behavior, which is a good practice in testing. However, ensure that all new functionality introduced in these tests is thoroughly tested to prevent any unexpected behavior. Additionally, consider adding more detailed comments or documentation to new test functions to improve maintainability and understandability for future contributors.

Consider adding more detailed comments or documentation to new test functions, enhancing maintainability and clarity for future contributors.

contracts/injective-cosmwasm-mock/src/testing/test_exchange.rs (10)

• 25-44: The test function test_msg_deposit correctly sets up the environment, executes a deposit message, and asserts the success of the operation. However, it's important to ensure that the error message in the assertion provides enough context for debugging in case of failure. Consider enhancing the error message to include more details about the failure.
• 47-61: The test function test_exchange_params effectively queries and asserts the correctness of exchange parameters. It's well-structured and follows best practices for testing. Ensure that the hardcoded values, such as the listing fee and trading rewards vesting duration, are aligned with the expected values from the contract's business logic or configuration.
• 64-127: The test function test_query_subaccount_deposit correctly performs deposit operations and queries to assert the correctness of the deposit amounts. It's important to ensure that the deposit amounts and denominations used in the test are representative of real-world scenarios to ensure the test's relevance. Additionally, consider adding negative test cases to cover scenarios where queries might fail or return unexpected results.
• 129-139: The test function test_query_spot_market_no_market_on_exchange correctly queries for a non-existent spot market and asserts the expected response. This test is crucial for ensuring the contract's robustness in handling queries for non-existent markets. Consider adding a comment to explain the significance of the hardcoded market ID used in the test, ensuring future maintainability.
• 184-239: The test function test_query_trader_spot_orders correctly adds spot orders and queries to assert the correctness of the orders' details. The assertions are detailed, ensuring the accuracy of price, quantity, and order type. However, the test could be improved by adding assertions for the order hash to ensure its correctness. Additionally, consider adding tests for edge cases, such as querying orders for a trader with no orders or querying orders in a non-existent market.
• 243-259: The test function test_query_spot_market_mid_price_and_tob effectively adds initial liquidity and queries to assert the correctness of the mid-price and TOB. The assertions are precise and cover the expected values for the mid-price, best buy price, and best sell price. Ensure that the liquidity addition is representative of realistic market conditions to ensure the test's relevance. Additionally, consider adding negative test cases to cover scenarios where the market is empty or the liquidity is skewed.
• 324-359: The test function test_query_market_volatility correctly adds orders and queries to assert the correctness of the market volatility calculation. The initial assertion of None volatility followed by an assertion of Some(FPDecimal::ZERO) after adding orders demonstrates the test's intent to verify the volatility calculation's sensitivity to market activity. Ensure that the test covers a range of market conditions, including high volatility scenarios, to fully validate the volatility calculation logic.
• 362-396: The test function test_query_aggregate_market_volume effectively adds orders and queries to assert the correctness of the aggregate maker and taker volumes. The test transitions from an initial state with zero volumes to a state with non-zero volumes after order additions, effectively demonstrating the query's ability to aggregate market volumes. Consider adding more diverse test cases to cover different types of market activities and their impact on aggregate volumes to ensure comprehensive testing of the volume aggregation logic.
• 399-421: The test function test_query_aggregate_account_volume correctly adds an order for a specific account and queries to assert the correctness of the aggregate volumes for that account. The test effectively demonstrates the query's ability to aggregate volumes on a per-account basis. However, the test could be enhanced by covering scenarios where multiple accounts contribute to the market's volume, ensuring the query logic accurately aggregates volumes across different accounts.
• 424-434: The test function test_query_market_atomic_execution_fee_multiplier correctly queries to assert the correctness of the market atomic execution fee multiplier. The assertion checks the multiplier value against a hardcoded expected value. Ensure that this hardcoded value is aligned with the contract's configuration or business logic. Additionally, consider adding tests to cover changes in the multiplier value under different market conditions or configurations, if applicable.